home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / June 96 / Re Re(2) Converting MacApp .2 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  4.5 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Re(2): Converting MacApp Example to ODF
  2. Sent:        6/1/96 11:11 AM
  3. Received:    6/3/96 7:58 AM
  4. From:        Owen J. Palmer, ojpalmer@fcom.com
  5. Reply-To:    ODF Interest, ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. John has exactly described our situation. 
  9.  
  10. We have already isolated the MacApp dependent code and broken the code 
  11. into modules which could become parts. One part would be a graphical 
  12. network designer tool based on ODFDraw. Another would be a data access 
  13. tool derived from the Calc example. Finally we have simulation and 
  14. optimization modules. These modules need to share structured data with 
  15. the parts efficiently.
  16.  
  17. Dr. Owen J. Palmer
  18. VP R&D
  19. US One Communicattions Corp.
  20.  
  21.  
  22. John Major wrote:
  23. > 
  24. > 'lo, folks -
  25. > 
  26. > I have a keen interest in converting/moving code back and forth between MacApp
  27. > and ODF, and spent some time at WWDC exploring this issue. I imagine that it
  28. > is of interest to a number of other folks as well, given:
  29. > 
  30. > - The large MA code base that could turn into OD part editors
  31. > 
  32. > - Apple's interest (and the "World at Large"!) in seeing many part editors
  33. > appear soon
  34. > 
  35. > - The MA code base's interest in going cross-platform
  36. > 
  37. > Let's assume that the MacApp team's vow at WWDC ("MacApp Reanimated") to bring
  38. > OD container support to MA will pay off ASAP - instant Internet apps! But what
  39. > I'm talking about is making MA code into a part.
  40. > 
  41. > A good sign here is that the ODF team and the MacApp team are now "under the
  42. > same roof", and appear to be cooperating effectively (some might view this as
  43. > very "Un-Apple" behavior, but there's a fresh wind blowing in Cupertino!).
  44. > It's hard, I imagine, as there are always internal rivalries and resource
  45. > battles about stuff like that, but here's hoping that they are striking the
  46. > right balance between bringing MA forward (and all the code out there that it
  47. > represents), and putting the muscle behind ODF that it requires to be a
  48. > success. I imagine that the key thing is that the *rest* of Apple needs to
  49. > have a clear understanding of how important these frameworks are to the
  50. > success of their OS technologies. This is something that Microsoft appears to
  51. > have understood from the get-go with MFC, and already making lots of money in
  52. > the Dev Tools business, had no problem putting all the oomph behind MFC that
  53. > it required. But now Apple, whatever the past history, is more and more in the
  54. > OS business, and needs to give these frameworks the resources they need to
  55. > support the OS.
  56. > 
  57. > On this note, then, I have to say that conspicuously absent from the picture
  58. > so far is a tool to move MA views to ODF, or better yet, to use them
  59. > simultaneously with both frameworks (given the excellent tools on the MA
  60. > side). There was even a note in the early Vger docs to the tune of "I'm going
  61. > to drop MA support, because I don't know anyone who's interested in this" -
  62. > ARGH! I imagine that I have lots of company, so speak up, folks... Spec Bowers
  63. > and AppMaker has the ability to generate ODF from his native resource format,
  64. > but he hasn't had time yet to do the fairly straightforward work of being able
  65. > to read in the MA views - so once again, speak up, MacAppers!
  66. > 
  67. > I'd be interested if any MA folks have a sense of how much of their app code
  68. > falls into the following categories:
  69. > 
  70. > - Completely or nearly independent of framework code - easy to share with an
  71. > OD part
  72. > 
  73. > - Completely or nearly restricted to isolated MA code modules - I'm thinking,
  74. > say, of complex dialog management code, with behaviors, dependencies, and the
  75. > like. It sounds like some of the lowest level stuff is migrating to this state
  76. > - something called "ODFLib" was mentioned at WWDC.
  77. > 
  78. > Could more chunks of MA be rewritten so that certain subsets of classes could
  79. > be used *either* in MA or ODF? Now *that* would be code reuse! Not only would
  80. > the Frameworks folks get reuse, but anyone who followed guidelines on the use
  81. > of those class subsets would get reuse. I'm assuming that there are folks like
  82. > me that want to migrate *pieces* of their app to part editordom as quickly as
  83. > possible, but still leave the monolithic app out there for some time to come.
  84. > 
  85. > Well, I've gone on too long - I'll be interested to hear what others have to
  86. > say.
  87. > 
  88. > John Major
  89. > Director, Software Development
  90. > AirGo Communications, Inc.,
  91. > Sorenson Research Park
  92. > 849 West Levoy Drive
  93. > Salt Lake City, UT 84123-2544
  94. > USA
  95. > jmajor@dayna.com
  96. > Tel: 801/269-7346
  97. > Fax: 801/269-7363
  98.